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1.  Executive  Summary 

The  objective  of  the  DARPA  Active  Templates  program  is  to  develop  lightweight  planning  tools  in  support 
of  special  operations.  Rockwell  Scientifics’  effort  culminates  in  two  software  systems:  CModeler,  a  causal 
modeling  Tool  and  SOFPlans,  a  graphical  planning  tool. 

This  report  is  focused  only  on  the  causal  modeling  tool  which  provides  a  capability  for  capturing  the 
cause/effect  constraints  in  a  special  operations  plan  and  for  reasoning  tasks  in  support  of  plan  execution. 
The  CModeler  tool  captures  automatically  a  default  causal  model  from  the  plan  authoring  input  entered  by 
users  using  domain  specific  interfaces,  e.g.  the  SOFTools  Temporal  Plan  Editor  (TPE)  in  the  special 
operations  domain. 

We  developed  a  computational  approach  based  on  the  notion  of  potential  causality  to  enable  building  a 
causal  model  elicitation  environment  that  automates  the  process  of  building  models  as  much  as  possible 
and  updates  those  models  incrementally  with  the  plan  authoring  input.  Instead  of  relying  on  knowledge 
bases  and  prior  domain  theories  as  in  traditional  knowledge  acquisition,  our  approach  uses  only  the 
temporal  ordering  of  the  actions  and  the  task  structure  of  the  plan.  The  term  “potential”  is  used  to 
emphasize  the  uncertainty  in  the  abduced  causal  ordering  since  no  requirement  is  made  on  the  existence  of 
a  complete  domain  theory  as  in  standard  partial  order  planning. 

We  give  in  this  report  a  formalization  and  algorithm  for  extracting  a  parsimonious  description  of  a  potential 
causality  relation,  which  is  presented  to  the  modeler  as  a  representation  of  the  candidate  space  of  sets  of 
causal  links  consistent  with  the  authored  plan.  We  describe  one  main  application  of  the  tool  for  the  special 
operations  planning  domain  to  support  the  task  of  run-time  replanning.  The  replanning  task  takes  the 
unexpected  events  in  the  execution  of  the  plan  (e.g.,  late  or  aborted  actions)  and  uses  the  causal  model  to 
compute  the  impact  on  future  actions  in  the  remainder  of  the  plan. 

We  give  in  this  report  a  general  formulation  of  the  task  of  abducing  potential  causality  from  plan  authoring 
input  in  a  mixed  initiative  framework  and  provide  a  high-level  description  of  the  reasoning  algorithms.  We 
give  an  example  of  a  plan  authored  in  SOFTools  and  describe  the  default  model  and  the  process  of  editing 
the  causal  graph.  We  use  the  same  example  to  show  how  the  causal  model  is  subsequently  used  to  support 
run-time  replanning.  The  last  sections  in  the  report  give  our  assessment  of  the  lessons  learned  and  our 
general  conclusions. 
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2.  Introduction 

In  standard  automated  planning  [Weld  1999]  the  goal  is  to  automatieally  synthesize  a  plan  from  a 
representation  of  goals,  states  and  operators.  A  plan  operator  is  typieally  represented  by  a  list  of 
preeonditions  and  post-eonditions  expressed  as  sentenees  in  some  formal  logie.  The  preeonditions  state 
whieh  eonditions  must  hold  before  an  operator  ean  be  exeeuted  and  the  post-eonditions  explieitly  state  the 
results  of  exeeuting  the  operator.  Generally  speaking,  automated  planning  amounts  to  a  seareh  for  an 
ordering  of  the  plan  operators  so  that  starting  from  the  initial  state,  the  operators  preeonditions  are  satisfied 
at  every  step  in  the  ordering  and  the  end  state  entails  the  goal  state. 

In  mixed  initiative  planning  (MIP)  plan  synthesis  uses  a  eollaborative  planning  paradigm  in  whieh  humans 
and  maehines  eollaborate  to  build  effeetive  plans  more  quiekly  and  with  greater  reliability  [Burstein  & 
MeDermott  1996].  The  MIP  approaeh  alleviates  the  requirement  for  eomplete  domain  models  as  in 
automated  generative  planners  and  makes  the  approaeh  viable  for  real-life  large-seale  planning  domains 
sueh  as  in  military  and  spaee.  In  MIP  Human  modelers  and  planning  algorithms  need  to  internet  more 
effeetively  in  order  to  develop  safe  effieient  plans,  and  tools  are  required  that  ease  the  task  for  the  modeler. 

Our  eausal  modeling  approaeh  aims  at  supporting  ease  of  plan  entry  during  MIP  in  whieh  a  human  planner 
authors  a  plan  by  formulating  the  planning  tasks  and  seleeting  and  ordering  the  aetions.  The  approaeh  takes 
the  plan  authoring  input  and  generates  a  eoneise  deseription  of  a  set  of  eausal  links  for  the  plan.  This 
eausally  linked  plan  ean  then  be  used  for  exeeution  monitoring  and  plan  revision  management. 

The  DARPA  Aetive  Templates  is  an  innovative  approaeh  to  MIP  in  whieh  human  planners  build  the  plans 
by  instantiating  and  linking  templates,  whieh  are  kind  of  frames  that  eonsist  of  attribute-value  pairs 
representing  stereotyped  tasks  or  situations  in  the  domain.  An  example  of  a  template  is  a  travel  planning 
template  [Frank  et  al.  2001]  where  the  attributes  may  inelude  origin,  destination,  weather,  transportation, 
ete.  In  general,  the  templates  maintain  built-in  eonstraints  and  the  attributes  ean  be  automatieally  defaulted 
using  speeialized  funetions  and  user  interfaees.  The  user  ean  also  assign  values  to  attributes  and  ean 
override  default  values. 

The  implementation  of  our  approaeh  in  the  CModeler  software  tool  [El  Fattah  2003],  is  eentered  on  the 
speeial  operation  planning  domain,  the  foeus  for  the  Aetive  Templates  program.  The  ontology  for  that 
domain  is  based  on  the  notion  of  movement  of  assets  from  one  plaee  to  another.  Plaees  represent  fixed 
geographie  loeations  over  spans  of  time  and  the  assets  represent  resourees  sueh  as  airerafts,  ships, 
helieopters,  vehieles  ete.  The  CModeler  program  has  a  number  of  interesting  eapabilities: 

>  Automatie  elieitation  of  eausal  models  by  interpreting  temporal  plan  plots,  input  from  the  user’s 
adopted  plan  authoring  interfaees  (SOFTools  TPE) 
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>  The  program  leverages  multiple  sourees:  the  predefined  ontology  of  the  domain,  the  plan  XML 
sehema,  the  preeedenee  ordering  of  the  plan  aetions,  the  loeality  relation  derived  from  the  plan 
task  hierarehy. 

^  The  program  enables  the  user  to  view  a  hierarehieal  layout  of  the  eausal  graph  eomputed 
automatieally  and  allows  the  user  to  amend  the  graph  by  adding  or  deleting  eausal  links. 

^  The  program  enables  abstraetion  operations  in  the  form  of  graph  folding  and  unfolding  to  allow 
users  to  view  the  eausal  model  at  the  desired  representation  levels;  i.e.,  by  shrinking  unneeessary 
details  and  expanding  interesting  portions  of  the  plan. 

^  The  program  enables  eonstraint  speeifieation  on  the  timing  of  the  aetions  and  embeds  a  versatile 
eonstraint  solver  (based  on  deelarative  eonstraint  logie  programming  CLP  formulation)  to  generate 
the  plan  sehedule  that  satisfy  all  eonstraints. 
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3.  SOF  Planning 

The  ontology  of  the  Speeial  Operation  Forees  (SOF)  planning  domain  is  based  on  the  notion  of  movement 
of  assets  from  one  plaee  to  another.  Places  represent  fixed  geographic  locations  over  spans  of  time  and  the 
assets  represent  resources  such  as  aircrafts,  ships,  helicopters,  vehicles  etc.  Figure  1  gives  a  partial 
specification  of  SOF  plan  objects  in  the  Unified  Modeling  Language,  UML.  The  Figure  says  that  a  plan  is 
composed  of  any  number  of  events,  movements,  and  places.  A  movement  has  a  start  and  an  end  which  are 
special  events,  and  is  associated  with  two  places  which  are  the  origin  and  destination  for  the  movement.  A 
place  or  a  movement  can  be  associated  with  any  number  of  events  which  are  local  to  the  place  or  the 
movement. 


An  event  has  type  which  can  be  plain  or  decisionpoint,  a  time  to  specify  when  the  event  should  occur  and  a 
calltime  to  specify  when  the  event  actually  occurs  during  execution.  A  place  has  a  time  interval  specified 
by  starttime  and  endtime,  and  a  name  intended  to  generically  identify  its  physical  location  (or  area  of 
operation,  in  the  case  of  a  “mobile  place”  like  a  ship)  and  its  role,  e.g.,  FSB  (forward  staging  base).  A 
movement  has  assets  which  are  the  resources  assigned  to  effect  the  move,  e.g.,  two  C-5  aircrafts. 


The  objects  in  Figure  1  also  define  the  plan  templates.  Each  template  is  a  list  of  variable  value  pairs;  the 
variables  being  the  attributes  of  the  objects  and  the  values  are  restricted  by  domain  constraints  and  the 
specified  relations  between  the  templates.  For  example,  the  duration  of  a  movement  is  a  function  of  the 
locations  of  the  origin  and  destination  of  the  movement  and  the  assets  used  by  the  movement.  An  example 
of  relations  between  the  templates  is  that  the  location  of  the  arrival  event  of  a  movement  is  the  destination 
place  for  the  movement. 
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Figure  3  Example  plan  in  SOFTools  TPE 


In  addition  there  also  are  integrity  constraints  enforced  on  the  timing  of  the  plan  events  and  tasks.  For 
example,  the  arrival  event  must  occur  later  than  the  departure  event  of  the  same  movement;  the  arrival 
event  be  earlier  than  the  endtime  for  the  destination  of  the  movement;  and  so  on.  See  Figure  2. 

Using  a  graphical  editor,  called  SOFTools  TPE,  a  planner  can  author  a  plan  by  a  drag  and  drop  of  graphical 
icons  representing  the  templates.  Events  and  decision  points  are  depicted  as  time  points  (diamond  shaped). 
Places  are  diagrammed  by  horizontal  lines  specifying  the  start  and  end  time.  Movements  are  represented  by 
arrows  directed  from  an  origin  place  to  a  destination. 
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An  example  of  a  plan  diagram  entered  in  SOFTools  that  we  will  use  throughout  this  report  is  shown  in 
Figure  3.  The  plan  ean  be  summarized  as  two  blaek-hawk  (MHhOs)  flying  to  objeetive  from  ship  to 
perform  a  “seeure  operation”  before  the  arrival  of  a  Chinook  (MH-47).  The  Chinook  flies  to  objeetive  from 
a  forward  staging  base  (FSB)  via  helieopter  landing  zone  (FILZ)  then  returns  to  FSB.  A  gunship  (AC- 
130U)  is  to  perform  the  fire  support  to  proteet  the  Chinook  flight  from  FSB  and  the  blaek-hawks  arrival  at 
objeetive.  The  fire  support  gunship  requires  aerial  refueling  (AR)  by  a  KC-135.  Notiee  that  some  of  the 
knowledge  in  our  narration  is  no  where  represented  in  the  plan  diagram.  Speeifieally  the  intention  of  using 
the  fire  support  for  the  purpose  of  proteeting  the  blaekhwaks  arrival  at  objeetive  is  not  explieitly 
represented.  Generally  speaking  the  plan  authoring  input  is  only  a  partial  speeifieation  of  a  plan  foeused 
only  on  the  extensional  representation  only.  The  intentional  representation  of  the  plan  is  not  explieitly 
speeified.  By  intentional  representation  we  mean  a  formal  speeifieation  of  eause/effeet  relations  between 
the  aetions  in  the  plan  that  enable  answering  queries  about  plan  ehange.  For  example  what  would  be  the 
effeet  of  an  event  sueh  as  the  start  of  the  fire  support  being  delayed?  In  the  absenee  of  knowledge  about 
eausal  links  it  is  not  possible  to  determine  what  effeet  sueh  event  will  have  on  other  events  in  the  plan  sinee 
we  do  not  the  independeneies  or  the  dependeneies  between  the  plan  aetions. 

The  main  motivation  for  this  work  has  been  to  provide  an  automated  tool  to  abduee  a  default  eausal  model 
from  the  extensional  temporal  .plan  representation.  We  foeus  on  the  stmeture  of  the  eause/  effeet  relations 
in  the  plan  and  represent  the  stmeture  in  the  form  of  a  direeted  aeyelie  graph  whose  nodes  are  the  plan 
events/  aetions  and  the  links  represent  “eausal  links”  and  “threat  resolution  links”  as  eommonly  defined  in 
partial-order  planning  [Weld  1999].  Informally,  a  eausal  link  is  a  link  between  an  aetion  pair  sueh  that  the 
posteondition  for  one  aetion  aehieves  a  preeondition  neeessary  for  the  other.  While  a  threat  resolution  link 
is  a  temporal  ordering  that  must  be  enforeed  to  proteet  preeonditions  one  aetion  be  elobbered  by  the 
posteonditions  of  the  other. 
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4.  Potential  Causality 

In  this  section  we  formalize  our  causal  modeling  approach  in  the  context  of  automated  planning.  We  give 
an  abstract  formulation  of  the  plan  authoring  input  and  a  general  statement  of  the  task  of  reasoning  about 
potential  causality. 

Plan  authoring  in  our  framework  is  a  triple  {T,  P,  p)  .  T  is  a  rooted  directed  tree  whose  nodes  V(T)  are  the 
plan  tasks.  The  root  of  the  tree  is  the  top-level  task  and  the  parent-children  relation  represents  task 
decomposition.  P  is  a  totally  ordered  (t.o.)  planP  =  (aj,...,a„> ,  represented  by  the  pair  {A,<p)  where  A  is 
the  set  of  actions  and  <p  is  a  total  order  defined  by  the  t.o.  plan:  for  1  <  i,j  <  n,  a-  <p  Uj  iff  i  <  j  . 
p  AxV  (T)  is  a  binary  relation  that  associates  the  actions  with  the  tasks. 

Given  a  plan  authoring  input  (P,  P,  p)  the  problem  we  pose  is  to  infer  a  partial-order  plan  (p.o.  plan)  given 
by  a  tuple  {A,-<}  where  ^  is  a  partial  order  on  A*.  The  partial  order  represents  a  parsimonious  description 
of  a  potential  causality  relation  on  the  actions  consistent  with  the  t.o.  planP.  We  represent  the  partial  order 
^  by  a  directed  acyclic  graph  (DAG),  G=(A,E),  called  causal  graph,  such  that  there  is  a  directed  path  from 
a,  to  Uj  in  G  iff  a,  ^  Qj  .  The  directed  edges  {ai,aj)  e  E  represent  both  “causal  links”  and  “threat  resolution 

links”  as  commonly  defined  in  partial-order  planning  [Weld  1999].  A  causal  link  from  to  a.  means 
a,  achieves  some  precondition  for  while  a  threat  resolution  link  is  a  temporal  ordering  that  must  be 

enforced  to  protect  conditions  achieved  by  some  causal  link.  The  causal  graph  G  represents  the  p.o.  plan 
which  is  a  compact  representation  for  a  set  of  t.o.  plans  that  can  be  obtained  as  the  topological  sort  of  G.  A 
topological  sort  of  G  is  a  sequence  obtained  by  ordering  the  nodes  A  such  that  if  {a.,aj)  e  E  then  is 

before  Uj  in  the  sequence. 


*  A  partial  order  is  a  binary  relation  that  is  irreflexive,  asymmetric  and  transitive.  A  binary  relation  on  a  set 
A  is  a  subset  Rc  XxX.  The  relationship  is  irreflexive  if  for  all  (x, x)  in  A x  A,  then  (x, x)  g  R.  The 
relationship  is  asymmetric  if  for  all  (x,  y)  e  R,  then  (y,  x)  g  R.  The  relationship  is  transitive  if  for  all  x,y,z  , 
if  (x, y)&  R  and  (y, z)gR  then  .  ia,,aj)  &E  {x,z)gR 
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Definition  1  Given  a  plan  authoring  input  Il-{T,P,p)-,  P  -{A, <p)  we  say  a  partial  order  ^  on^  is  a  11- 
compatible  potential  causality  order  if  it  satisfies  the  following  postulates:  (i)  the  total  order  -<p  obeys  the 
partial  order  ^  ,i-e.,  (ii)  if  two  actions  belong  to  same  task  teV(T),  i.e.,  (a^,t)  e  p  and 

(aj,t)£  pthen  the  actions  must  be  ordered  following  the  t.o.  plan,  i.e.,  a-  ■<  Oj  if  i<  j  and  Uj  ^  a,  if 
j  >  i  (iii)  if  two  actions  belong  to  tasks  t^,tj  e  V{T)  ,i.e.,  (a,,t,)  e  p  and  (fljp-')  e  p  such  that  either 
t,  or  t.  is  an  ancestor  of  the  other  in  T,  then  the  actions  must  be  ordered  following  the  t.o.  plan,  i.e., 
a,  <  a,,  if  i  <  j  else  a,  <  a, . 

The  intuition  behind  the  potential  causality  postulates  is  as  follows.  The  temporal  ordering  of  the  actions 
for  each  task  guarantees  that  each  action  has  effects  that  are  required  by  the  preconditions  of  the  later 
actions  in  the  same  task  and  therefore  provide  sufficient  condition  on  the  causal  ordering.  The  tasks  whose 
actions  do  not  overlap  (do  not  share  actions)  are  likely  to  be  independent  and  could  be  executed  in  any 
order.  Tasks  that  are  ancestor  (or  descendant)  of  one  another  in  the  tree  are  potentially  inter-dependent  and 
therefore  their  temporal  ordering  should  be  preserved  by  the  causal  ordering.  Potential  causality  provides  a 
space  of  partial  orders  from  the  most  to  least  constrained.  The  most  constrained  order  is  the  input  plan 
ordering  -<p  which  is  a  complete  ordering.  The  least  constrained  causal  order  can  be  defined  using 
optimization  criteria  such  as  set  minimality  as  defined  next. 

Definition  2  Given  two  IT-compatible  potential  causality  orders  P  =  iA,p  )  and  P  '  =  iA,p  ')  we  say  that 
P  '  is  less  constrained  than  iff  p  'Ip  .A  Tl-compatible  potential  causality  order  P  =  (A,p  )  is  minimal 
iff  there  is  no  other  IT-compatible  potential  causality  order  P  '  ^  (A, p  ')  such  that  P  'is  less  constrained 
than  P. 

Example  1.  Consider  the  planning  problem  of  putting  shoes  and  socks.  A  plan  authoring  input  will  have: 
(i)  a  tree  T  with  a  root  node  and  two  leaves  which  are  the  primitive  tasks  right  foot  and  left  foot;  (ii)  a  t.o. 
plan  e.g.,  <start,  left  sock,  left  shoe  ,right  sock,  right  shoe,  finish);  (iii)  mapping  of  actions  to  primitive 
tasks:  {(start  ,plan), (finish,  plan),(left  sock,  left  foot)  ,(left  shoe,  left  foot),  (right  sock,  right  foot),  (right 
shoe,  right  foot)}.  Here  start  and  finish  are  “dummy”  actions  to  encode  the  initial  state  and  the  goal  state  for 
the  plan  task  which  is  the  root  node  of  the  tree.  It  is  easy  to  see  that  a  minimal  potential  causality  order  is 
represented  by  the  causal  graph  having  the  directed  edges  {start— >right  sock,  start— >left  sock,  right  sock 
aright  shoe,  left  sock  — >left  shoe,  left  shoe  — >fmish,  right  shoe  —> finish}.  The  graph  is  a  compact 
representation  of  6  possible  t.o.  plans. 


We  now  describe  a  polynomial  time  algorithm  that  computes  a  minimal  potential  causality  graph  (PCG) 
from  a  plan  authoring  input.  The  algorithm  has  two  main  steps.  In  the  first  step  it  computes  a  minimal 
potential  causality  order  ^  starting  from  the  complete  input  plan  order  1  and  in  the  second  returns  a 
directed  acyclic  graph  (DAG)  from  the  transitive  reduction  of  the  partial  order.  The  transitive  reduction  can 
be  computed  in  0(\  A\- 1^|) . 

Algorithm  PCG 

Input:  authored  plan  n=(T,P,/?);  P=(A,  ^p) 

Output:  potential  causality  graph,  G 
begin 

^  <—  -<P  // initialize  partial  order 
//  compute  minimal  potential  causality  order 
for  each  {a, a') 

S  =  {t  eV (T)  I  (a,  t)  e  /?}  //  tasks  for  a 
S'  =  {t^V{T)  |(a',C)e  p)  H  tasks  fora' 
violation  <—  false 
repeat  while  — i  violation 
for  each  t  e  S'  and  t'  ^  S' 
if  S  nS'  ^0  then  violation  <—  true 
else  if  C  ^  desc(t)  At  ^  desc(C)  then  violation  <—  true 
loop 

if —1  violation  then  ^  <—  ^-{(a,a')} 

//causal  graph  as  transitive  reduction 
return  minimal  DAG,  G  =  (A,E),  such  that  there  is  a 
directed  path  from  a  to  a'  iff  a  ^  a' 

End 
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5.  Causal  Modeler 

We  built  a  tool  that  implements  our  approach  for  inferring  potential  causal  links  in  the  SOF  planning 
domain.  The  tool,  called  Causal  Modeler  (or  CModeler)  [El  Fattah  2003]  captures  cause/effect  models  from 
SOFTool  plans  based  on  potential  causality  (e.g.  aircraft  arrival  depends  on  aircraft  departure)  CModeler 
can  generate  plans  using  the  causal  information  and  can  automatically  revise  plans/  schedules  when  events 
occur  late  or  are  aborted  and  automatically  update  SOF  execution  checklist.  The  computing  architecture  is 
shown  in  Figure  4. 


Plan  authoring  Call  time  Causal  modeling 


Temporal 

Plan 

Editor 

Event 

Check 

List 

Editor 

Recon 

Causal 

time 

figuration 

Editor 

XML 


Figure  4  Causal  Modeler  architecture 
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Figure  5  Causal  modeler  showing  default  graph. 


CModeler  provides  two  dynamic  execution  capabilities  for  computing  the  effect  of  change  during 
execution  and  for  updating  the  plan  execution  checklist.  The  changes  currently  supported  are  aborted  and 
delayed  events.  The  causal  models  are  represented  as  directed  graphs  whose  nodes  are  plan  elements  (type 
movements;  places;  events  and  decision  points)  and  the  edges  are  directed  from  causes  to  effects.  The 
structure  of  the  causal  model  is  represented  as  compound  graph  visualized  in  two  views:  tree  view  and 
graph  view.  The  tree  view  shows  the  plan  task  hierarchy  and  the  graph  view  shows  the  causal  graph 
induced  by  contracting  or  expanding  nodes  in  the  tree.  Figure  5  shows  CModeler  displaying  the  default 
causal  graph  for  the  plan  example  shown  in  Figure  3. 

CModeler  allows  full  graphical  editing  capabilities  for: 

a)  adding/  removing  causal  links  between  events 

b)  adding/  removing  plan  elements 
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c)  editing  properties  of  plan  elements  as  in  SOFTools.  CModeler  applies  causal  heuristics  to  infer  default 
causal  model  incrementally  as  plan  elements  are  added.  A  user  can  enable/disable  the  default  causal 
modeling  by  selecting  or  deselecting  the  use  of  heuristics  from  CModeler’ s  menu.  If  the  heuristics  are 
deselected  then  no  causal  links  are  created  automatically  in  the  graph  view  and  the  user  can 
graphically  enter  the  causal  dependencies. 

CModeler  provides  two  ways  to  build  causal  models  (1)  interactive  way  -  by  authoring  a  plan  interactively 
in  CModeler;  (2)  non-interactive  way-  by  authoring  a  plan  in  the  SOFTools  TPE  then  loading  the  plan  into 
CModeler 


Having  an  automated  tool  for  default  causal  modeling  has  fdled  a  need  in  this  SOF  planning  domain  for 
eliciting  and  capturing  causal  knowledge  during  the  plan  authoring.  The  causal  views  computed  by 
CModeler  are  linked  to  the  temporal  and  spatial  plan  views  so  that  changes  in  one  view  can  propagate  to 
the  other  views.  This  is  done  by  representing  and  capturing  the  temporal  plan  constraints  and  the  causal 
dependencies  between  the  actions  in  the  plan.  By  viewing  the  default  causal  graph  a  user  is  able  to 
determine  if  causal  links  are  missing  or  existing  ones  are  spurious  and  can  amend  the  default  model  by 
appropriately  adding  or  deleting  causal  links. 

Incremental  Causal  Construction 

CModeler  applies  the  heuristics  as  the  user  is  plotting  the  temporal  plan  diagram.  The  heuristics  are  local  to 
action  subsets,  enabling  incremental  construction  of  causal  models.  The  basic  idea  of  the  incremental 
constraction  is  a  splicing  operation;  at  each  step  replacing  arcs  in  existing  causal  model  by  chains 
containing  new  nodes.  Figure  6  shows  a  splicing  operation  after  adding  a  plan-event  type  action  to  the  plan. 
The  Figure  shows  the  colored  node  Act  i  being  added  to  the  task  tree  and  spliced  in  the  current  causal 
model  by  removing  an  edge  between  two  nodes  (the  predecessor  and  successor  in  the  temporal  sequence) 
and  adding  a  chain  that  links  the  new  node  to  its  neighbors.  CModeler  maintains  two  data  structures  for 
plan  authoring  the  task  tree  and  the  causal  graph.  At  each  step  in  plan  authoring  a  user  can  add  to  the  plan  a 
new  object:  a  place  task;  a  movement  task;  or  an  action  of  type  plan-event,  place-event,  movement-event, 
or  decision-point.  CModeler  interprets  the  added  object  and  will  perform  any  of  these  splicing  operations: 


12 


Figure  6  Causal  modeler  showing  the  default  causal  graph. 


>  If  plan  element  is  a  plaee  then  add  a  plaee  node  to  the  tree. 

>  If  plan  element  is  a  movement  then  add  a  movement  node  to  the  tree  and  ereate  two  graph  nodes 
for  depart  and  arrive  events  and  a  eausal  link  between  them 

>  If  the  plan  element  is  an  event  bound  to  a  plaee  (movement)  then  add  a  ehild  to  the  respeetive 
plaee  (movement)  node  in  the  tree  and  spliee  the  event  node  in  the  plaee  (movement)  subgraph 

^  If  the  plan  element  is  a  plan  event  (deeision  point)  then  add  a  node  to  the  tree  and  spliee  the  event 
(deeision)  in  the  plan  event  (deeision)  subgraph. 

Abstraction 

For  a  large  plan  eontaining  a  large  number  of  aetions  the  eausal  graph  ean  beeome  too  large  to  visualize 
and  details  beeome  obseured.  CModeler  supports  two  abstraetion  strategies:  (a)  folding:  whieh  eoneeals 
“unwanted”  details  of  a  graph  allowing  a  user  to  temporarily  hide  eertain  nodes  and  edges  and;  (b) 
unfolding:  whieh  reintroduees  the  hidden  details  of  folded  nodes.  At  any  time  during  a  sequenee  of  folding 
or  unfolding  operations,  the  eausal  graph  has  a  valid  topology  allowing  a  user  to  perform  layout.  Thus, 
folding  and  unfolding  ean  be  used  to  eoarsen  and  refine  eausal  graph  abstraetions  and  to  ereate  new 
summary  views,  ealled  eausal  views.  We  use  the  plan  task  hierarehy  as  a  basis  for  eomputing  abstraetion 
views  of  the  eausal  graph.  The  abstraetion  views  are  nested  graphs  [Sugiyama  and  Misue,  1991] 
(sometimes  ealled  a  hierarehieal  or  eompound  graph)  allowing  nodes  to  eontain  graphs.  Eaeh  view  is 
depieted  as  a  direeted  graph  whose  nodes  eontain  blobs  denoting  sets  of  nodes  in  the  eausal  graph.  Every 
set  of  interest  is  represented  by  a  unique  blob  and  is  labeled  by  an  assoeiated  task  in  the  plan.  The  eausal 
views  have  direeted  edges  indueed  from  the  eausal  graph  as  shown  in  Figure  7.  The  Figure  shows  that  an 
edge  from  node  b  to  node  e  in  the  eausal  graph  induees  an  edge  from  the  blob  T2  to  the  blob  Tl.  At  the 
most  abstraet  level  the  eausal  view  will  have  just  one  blob  eontaining  the  entire  graph. 
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CModeler  shows  causal  views  as  a  pair:  a  tree  and  a  directed  graph  as  shown  in  Figure  5.  The  views  are 
coupled  so  that  the  leaves  in  the  tree  view  always  match  up  with  the  nodes  in  the  graph  view.  Initially  the 
tree  in  the  tree  view  is  the  task  hierarchy  and  the  graph  in  the  graph  view  is  the  “flat”  causal  graph.  To  fold 
an  internal  node  in  the  tree  view,  a  user  clicks  the  minus  (-)  sign  next  to  the  node.  This  contracts  the  node  in 
the  tree  view  and  coarsens  the  graph  view  by  hiding  the  subgraph  for  the  descendants  of  the  contracted 
node  inside  a  blob  matching  the  contracted  node  in  the  tree  view.  Blobs  are  shown  as  rectangles  and  plan 
actions  or  events  are  shown  as  ellipses. 

To  unfold  a  node  in  the  tree  view,  a  user  clicks  the  plus  (+)  sign  next  to  the  node  in  the  tree  view. 

Unfolding  will  expand  the  tree  one  level  below  the  unfolded  node  showing  the  children  of  that  node  in  the 
tree  view  and  the  subgraph  for  the  children  in  the  graph  view.  Induced  edges  are  created  dynamically  to  and 
from  the  blobs  in  the  graph  views  to  maintain  consistency  with  the  “flat”  graph.  An  induced  edge  is  created 
from  (to)  a  blob  if  there  exists  an  edge  in  the  graph  view  from  (to)  a  descendant  of  the  blob.  Note  that 
unlike  the  causal  graph  which  is  acyclic,  the  abstracted  causal  views  may  contain  directed  cycles.  For 
example,  if  in  Figure  7  there  is  an  additional  arc  from  node  a  to  node  d  then  there  will  be  a  directed  cycle 
between  the  blobs  T1  and  T2.The  folding  and  unfolding  explorations  to  coarsen  and  re-fine  the  causal 
views  interactively  can  be  implemented  efficiently  in  time  linear  in  the  number  of  changes  induced  by  any 
exploration  operation  [Buchsbaum  and  Westbrook,  2000] 


Task  hierarchy 


Figure  7  Causal  views 
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6.  Constraint  Processing 

To  enable  specification  of  temporal  constraints  on  the  plan  tasks,  we  use  the  causal  graph  to  define  a 
temporal  constraint  network.  Temporal  constraints  are  assigned  to  the  nodes  and  edges  of  the  graph  and  the 
solution  to  the  constraint  network  determines  the  start  and  finish  dates  for  all  the  plan  tasks. 

A  solution  of  a  constraint  network  is  an  assignment  of  values  to  the  variables  that  satisfies  all  the 
constraints.  A  constraint  network  is  consistent  if  there  exists  a  solution.  A  constraint  network  is  minimal  if 
each  primitive  constraint  is  satisfied  in  a  solution  of  the  network;  i.e.  there  are  no  primitive  constraints  that 
do  not  participate  in  at  least  one  solution.  Interesting  problems  (typically  NP-hard)  are  to: 

(a)  determine  consistency 

(b)  compute  the  minimal  network 

(c)  compute  one  or  all  solution(s) 

(d)  check  consistency  of  an  assignment 

We  restrict  ourselves  to  binary  constraint  networks.  The  value  domain  is  the  real  domain  for  all  the  time 
variables.  The  constraint  specification  for  the  plan  events  depend  on  whether  the  event  is  independent,  i.e., 
having  no  parents  in  the  causal  graph.  If  the  event  has  parents  then  the  constraints  are  specified  as  the 
minimum  lag  time  from  each  parent  that  the  event  depends  upon.  If  the  event  is  independent  then  the 
constraint  is  specified  as  either  before,  on,  or  after  the  H-hour.  Minimum  lead  time  is  specified  for  the 
before  constraint  and  minimum  lag  time  for  the  after  constraint  which  both  translate  to  inequality 
constraints.  For  the  on  constraint  a  lead  or  lag  time  can  be  specified  which  translates  to  an  equality 
constraint. 
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The  default  eonstraints  abdueed  from  the  temporal  plan  are  speeified  as  follows: 

>  For  each  independent  event  (root  node  in  the  causal  graph)  the  constraint  is  before  or  after 
constraint  with  a  minimum  lead  or  lag  time  specified  by  the  difference  between  the  event  time  and 
the  Fl-hour. 

>  For  each  dependent  event  (having  parents  in  the  causal  graph)  create  constraint  for  each  directed 
edge  and  specify  a  minimum  lag  time  computed  as  the  difference  between  the  event  time  and  the 
time  for  its  parent.  The  constraint  for  the  dependent  event  is  a  set  of  inequalities;  each  specifying 
the  time  for  the  event  minus  the  time  for  the  parent  be  greater  or  equal  the  minimum  lag  time 
specified  for  the  respective  edge  in  the  causal  graph. 

As  an  example  consider  the  temporal  plan  shown  in  Figure  8.  The  plan  consists  of  two  bases,  a  movement 
from  one  base  to  the  other  and  a  place  event  at  each  base.  The  default  causal  graph  is  shown  in  Figure  9. 


The  default  constraints  abduced  for  the  model  is  shown  in  Figure  10.  There  are  two  independent  events  in 
the  graph  which  are  the  base  event  #1  and  base  event  #2.  The  Figure  shows  the  constraint  for  base  event  #1 
being  before  Fl-hour  with  a  lead  time  computed  from  the  temporal  plan.  An  example  of  dependent  event  is 
“Dpt  base”  which  has  one  parent  “Base  event  #1”  and  the  constraint  is  a  lag  time  constraint  relative  to  the 
parent  with  the  lag  computed  from  the  difference  between  the  event  time  of  “Dpt  base”  and  that  of  the 
parent.  All  the  default  constraints  are  given  by  inequalities  with  the  value  domain  being  the  real  values.  The 
variables  are  the  event  times  for  the  events  in  the  plan  plus  the  time  of  the  plan  Fl-hour.  For  the  example, 
there  are  4  variables  and  there  are  5  constraints:  2  for  the  2  root  nodes  plus  a  constraint  for  each  directed 
edge  in  the  causal  graph. 
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The  solution  for  the  constraint  problem  is  computed  by  a  constraint  solver  using  the  constraint  logic 
programming  language  over  real  domain  CLP(R).  A  query  is  created  by  assembling  all  the  temporal 
constraints  and  assigning  a  temporal  variable  for  each  event.  There  can  be  many  solutions  that  satisfy  the 
constraints.  To  restrict  the  set  of  solutions  we  formulate  the  problem  as  an  optimization  problem  by 
minimizing  the  sum  of  all  the  event  times.  For  our  simple  plan,  the  constraint  query  is  stated  as  follows: 


schedule ( [TO,  Tl,  T2,  T3,  T4]):- 

{TO  >=  0,  Tl>=  0,  T2>=  0,  T3>=  0,  T4>=  0,  TO-Tl  >=  7248, 
T0-T2  >=  5808,  T3-T1>=  1248,  T4-T2>=  3888,  T4-T3>=  4080, 
Z=T0+  T1+  T2+  T3+  T4}, 
minimize (Z) . 

The  solution  returned  is  as  shown  in  Figure  1 1 .  Notice  that  the  solution  generally  differs  from  the  initial 
values  assigned  in  the  original  temporal  plan.  For  example,  both  the  independent  events  are  assigned  the 
same  time  while  in  the  initial  plan  they  are  not. 
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7.  Knowledge  Capture 
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Figure  12  Potential  causality  graph  with  thick  arcs  added  by  domain  expert 


An  important  result  of  our  work  is  that  it  enables  round-trip  engineering  between  the  causal  and  temporal 
representations  of  a  plan.  Planner  in  our  SOF  domain  are  accustomed  to  authoring  plans  based  on  the 
temporal/spatial  view.  Having  an  automated  tool  for  default  causal  modeling  has  fdled  a  need  for  eliciting 
and  capturing  causal  knowledge  during  the  plan  authoring.  This  means  capturing  and  explicitly 
representing  the  plan  constraints  and  the  causal  dependencies  between  the  events  in  the  plan. 
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By  viewing  the  default  causal  graph  a  user  is  able  to  determine  if  some  causal  links  are  missing  and  can 
amend  the  default  model  by  adding  or  deleting  links  Our  heuristic  approach  provides  “useful”  results  with 
incomplete  information  and  the  results  improve  as  additional  knowledge  sources  become  available,  e.g. 
additional  heuristics  and  more  complete  specification  of  plan  constraints. 

For  example,  the  default  causal  model  shown  in  Figure  12  has  some  of  the  causal  relationships  unspecified. 
Those  are  the  relationships  between  the  fire  support  and  their  objectives  and  between  the  aerial  refueling 
and  the  fire  support.  They  are  missing  in  the  default  model  because  no  transaction  constraints  were 
specified. 

To  amend  the  default  causal  graph  the  user  will  add  those  causal  links  as  shown  in  Figure  3  in  thick  lines. 
The  Figure  shows  6  causal  links  added  to  the  default  model.  Link  1  says  the  start  of  the  fire  support 
necessitates  the  start  of  aerial  refueling  movement.  Link  2  says  that  being  at  aerial-refueling  track  enables 
the  refueling  action.  Links  3,  4  specify  the  causal  condition  for  the  supported  missions  to  begin.  The  causal 
links  say  the  fire  support  “on-station”  event  enables  the  two  Blackhawk  to  depart  Ship  and  the  Chinooks  to 
depart  drop  zone  Copper.  Links  5,  6  specify  the  causal  condition  when  the  fire  support  is  to  end.  The  links 
say  that  the  departure  of  both  the  Chinooks  and  the  Blackhawk  from  objective  Gold  enables  fire  support 
“off-station”  event. 
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8.  Dynamic  Execution 

One  of  the  main  functions  enabled  by  our  CModeler  program  is  the  support  for  dynamic  plan  execution. 
Most  plans  do  not  execute  according  to  schedule  and  when  this  occurs  there  is  limited  time  to  respond. 
When  changes  occur  during  execution,  the  task  of  plan  reconfiguration  consists  in  determining  all  actions 
impacted  by  the  change  and  recomputing  the  plan  schedule  to  meet  known  constraints  on  the  affected 
actions.  The  affected  actions  can  be  determined  by  performing  a  reachability  analysis  on  the  causal  graph. 
For  example,  if  an  action  such  as  the  departure  of  an  aircraft  is  delayed  then  we  must  delay  all  its  causally- 
dependent  actions  (its  descendants  in  the  causal  graph),  e.g.,  the  arrival  of  the  aircraft  at  destination  and  the 
arrival-dependent  chain  of  events.  Note  that  those  descendants  are  not  necessarily  contiguous  in  the  plan 
execution  checklist  making  the  determination  of  causal  impact  non-trivial.  Also  the  temporal  relationships 
inferred  from  the  plan  temporal  diagram  are  not  adequate  to  determine  the  required  reconfiguration.  For 
large  plans  the  reconfiguration  task  can  be  difficult  and  time-consuming  to  perform  without  automation. 
We  have  implemented  the  following  algorithm  for  plan  reconfiguration  (PR)  in  CModeler. 

Algorithm  PR 

Input:  checklist  L;  causal  graph  G=(A,E). 

Output:  reconfigured  checklist  L'  . 

begin 

S^0  //execution  state 

<a^,...,  a,,>^topological  sort  of  G 

for  i=l  to  n  do 

if  (calltime  (a., L)  =? )  //not  yet  executed 
then  if  //has  some  parent  in  abort  state 
(x  in  pa(a.,G)  :  state  (x,  abort)  in  S) 
then  //set  action  state  to  abort 
S^Su{  state  (a. ,  abort)  } 
else  //  max  delay  of  the  parents 

A=max{  I  xepa  (a. ,  G)  ,  state  (x,  delay  (A^,  eS} 

S^Su{  state  (a. ,  A)} 

else  if  //action  has  been  aborted 
(calltime  (a. ,  L)  =abort) 
then  //set  action  state  to  abort 
S^Su{  state  (a.,  abort)  } 
else  //compute  delay 

A=r  calltime  (a.,  L)  -  eventtime  (a. ,  L)  1 
for  i=l  to  n  do 
if  (state  (a.,  abort)  e  S) 
then  eventtime  (a., L) ^abort 
if  (state  (a.,  delay  (A)  )  e  S) 
then  eventtime  (a.,  L)  ^  eventtime  (a^,  L)  +  A 
return  L'^ 
end. 
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The  plan  reconfiguration  algorithm  PR  takes  the  plan  causal  graph  and  the  execution  state  and  outputs  an 
updated  checklist  of  the  plan.  A  plan  execution  state  consists  of  a  determination  in  real-time  for  each  event, 
relative  to  its  call  time  and  scheduled  time,  whether:  the  event  is  late;  has  not  occurred;  been  aborted;  called 
in  early;  called  in  on  time;  called  in  late.  Our  reconfiguration  algorithm  first  orders  the  events  along  a 
causal  order  which  is  just  a  topological  sort  of  the  causal  graph  (which  is  acyclic).  The  algorithm 
propagates  the  execution  state  by  aborting  an  event  if  any  of  its  parents  is  aborted;  otherwise  delaying  the 
event  by  the  maximum  delay  over  its  parents.  The  algorithm  shifts  the  scheduled  time  for  delayed  events 
and  outputs  a  new  execution  list  ordering  the  events  by  increasing  event  time. 


Figure  13  Reconfigured  plan  after  fire  support  delayed  1  hour 
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Figure  13  shows  a  reconfiguration  example  for  our  SOF  plan  of  Figure  3,  where  the  depart  event  of  the  fire 
support  gunship  (AC-130U)  is  delayed  1  hour.  The  reconfiguration  is  computed  based  on  the  amended 
causal  graph  shown  in  Figure  3.  Compared  to  the  original  plan  in  Figure  2,  we  see  that  (a)  the  event  of  KC- 
135  at  air-refueling  track  is  shifted  back  1  hour;  (b)  the  departure  of  the  chinook  from  Copper  and  the 
Blackhawk  from  Shipl  are  all  shifted  by  same  amount  to  meet  the  fire-support  coverage  constraint;  (c)  all 
causally  dependent  events  are  properly  shifted;  (d)  all  independent  events  remain  unchanged,  e.g.  the 
decision  point  the  departure  of  the  Chinook  from  baseX  and  arrival  to  Copper.  Note  that  the  end  times  for 
places  are  shifted  by  proper  amount  to  satisfy  the  condition  that  reconfigured  place  events  be  within  the 
start  and  end  time  for  the  place. 
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9.  Plan  Reuse 

Our  causal  modeling  approach  can  speed-up  plan  authoring  by  reusing  previous  cases  from  an  experience 
library.  The  plan  reuse  consists  of  two  parts:  (1)  retrieval  of  existing  plans  from  the  experience  library  that 
resemble  current  partial  plan;  (2)  adaptation  of  retrieved  plan  to  extend  and  complete  current  partial  plan. 

An  important  task  is  to  determine  similarity  between  existing  plan  and  current  partial  plan.  We  assume  that 
previous  plans  are  cached  as  cases  in  an  experience  library  and  each  case  consist  of  a  plan  annotated  with 
its  causal  model. 

Causal  graphs  provide  a  structured  framework  for  computing  similarity  between  plans.  During  plan 
authoring  we  can  start  with  a  partial  plan  and  query  a  historical  database  for  best  matching  completed 
plans.  Once  we  have  a  matching  plan  and  a  mapping  between  similar  parts  of  the  plan  we  can  then  adapt 
the  matching  plan  to  construct  a  suitable  current  plan.  The  matching  can  be  performed  at  different  levels  of 
abstraction. 

The  following  is  an  algorithm  for  computing  the  similarity  between  pairs  of  plans.  Similarity  is  evaluated 
using  an  index  between  0  and  1,  with  0  indicating  no  match  1  perfect  match  and  the  higher  the  index  the 
better  the  match.  The  algorithm  compares  pairs  of  plans  based  on  their  causal  models. 

Algorithm  P-Sim 

Input:  Two  causal  graphs  Gl,  G2  of  two  distinct  plans. 

Output:  Similarity  measure  between  the  two  plans 

Begin 

Compute  causal  orders  dl=  (u^, ...,  u,^^} )  ,  d2=  (v^, ...,  for  Gl  and  G2  ; 
k  <k, . 

index^l;  #matches^0 
for  1  =  1  to  kj 
match^f alse 
j  = index 

while  (not  matchAj<kJ 

if  (type  (u.)  =  =  type  (v.)  )  a  (  |  pa  (u. )  |  ==pa  (v. )  |  ) 
then  match=true; 
j=j+l 
if  (match) 

then  #matches^#matches  +  l ;  index^j 
return  Similarity_index  =  ttmatches/k^; 

End. 


23 


2WJZ 


nm 


2t}]Z 

H-li 

- >— 


00002 

21^00 


mz 

H^lk 


020Z 

K*7k 


mz 

H*yk 


(M»Z 


mz 

H*3b 


Team  1 


Figure  14  Two  plans:  Teaml  is  air-based  and  Team2  is  sea-based. 


The  idea  of  the  algorithm  is  to  order  the  nodes  in  a  eausal  ordering  and  determine  for  eaeh  pair  of  nodes 
whether  they  mateh  based  on  their  type  and  the  number  of  parents  (i.e.,  the  size  of  the  eausal  families).  The 
algorithm  ean  be  applied  to  eompare  plans  based  on  task  views  (see  Seetion  5.2)  by  first  folding  the  eausal 
graphs  and  then  applying  the  algorithm  to  the  folded  eausal  graphs  where  nodes  are  blobs  representing  plan 
tasks,  eaeh  eontaining  subsets  of  events.  If  the  folded  graphs  have  eyeles  then  it  ean  be  redueed  to  an 
aeyelie  graph  by  lumping  the  strongly  eonneeted  eomponents  in  super  blobs  and  then  eomparing  the 
redueed  graphs. 
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Figure  14  shows  two  SOF  plans  one  air-based  ealled  Teaml  and  the  other  sea-based  called  Team2.  Figure 
15  shows  the  causal  graphs  for  both  plans.  The  Figure  also  shows  a  causal  ordering  of  the  nodes  in  the 
graphs.  Clearly,  there  is  a  very  close  match  between  the  two  plans:  7  out  of  8  nodes  in  the  graph  of  plan-1 
match  respective  nodes  in  the  graph  of  plan-2.  The  similarity  mapping  between  plan-1  and  plan-2  is:  1^1, 


2^2,  3^4, 4^5,  5^6,  6^7,  8^10. 


Figure  15  Comparing  two  causal  graphs 
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1 0.  Related  Work 

There  has  been  work  on  capturing  plan  rationale  and  causal  structure  recovery  of  plans  in  the  context  of 
partial  order  planning  [Kambhampati  &  Kedar  1994],  case-based  planning  [Veloso  &  Carbonell  1993],  and 
MIP  [Veloso  1996].  A  plan  rationale  aims  to  explicate  why  a  plan  is  the  way  it  is  or  the  reason  as  to  why 
the  plan  decisions  are  taken.  Unlike  previous  work  which  requires  complete  domain  theory  of  the  planning 
domain,  our  approach  can  generate  potential  causal  links  in  the  plan  by  analyzing  the  temporal  ordering  and 
the  task  stmcture  of  the  plan.  Requiring  complete  domain  models  or  expecting  the  human  planner  to 
specify  every  condition  required  by  the  plan  operators  is  not  realistic  in  large  real-life  planning  applications 
such  as  in  military  and  space.  Our  approach  complements  another  direction  of  research  in  AI  planning 
focused  on  qualitative  reasoning  about  plans  [Myers  2001].  In  that  research  the  focus  is  on  qualitative 
cause-effect  relations  and  on  calculus  for  reasoning  about  change.  Our  work  is  complementary  in  the  sense 
that  it  offers  an  approach  for  initial  causal  models  that  can  be  supplemented  with  qualitative  knowledge  to 
address  the  problem  of  lack  of  complete  domain  models. 

In  automated  planning  there  has  been  work  on  the  problem  of  removing  unnecessary  orderings  in  a  total 
order  plan  (linear  plan)  in  order  to  produce  a  “least  constrained”  [Veloso  et  al.  1990]  or  “shortest  parallel 
execution”  [Regnier  &  Fade  1991]  partial-order  plan.  It  has  been  shown  that  the  problem  is  generally  NP- 
hard  [Backstrom  1993].  Our  work  differs  in  that  our  partial  order  is  representing  potential  causal  links 
without  requiring  a  domain  theory  and  an  automated  plan  validity  test  as  in  [Backstrom  1993]. 
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Figure  16  Temporal  plan  schema  for  SOFTools. 
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1 1 .  Lessons  Learned 

The  focus  of  our  effort  in  the  initial  phase  of  the  program  had  been  to  develop  a  relational  database  schema 
for  active  templates  and  a  set  of  tools  for  analyzing  the  cause-effect  relationships  between  assets,  actions, 
and  objectives  in  a  plan.  Specifically  we  built  a  relational  schema  and  a  program  that  maps  the  temporal 
plan  XML  file  to  the  database.  We  advocated  that  bringing  planning  into  the  realm  of  relational  databases 
has  several  advantages.  Databases  provide  robust  mechanisms  (commit/rollback)  for  distributing 
applications.  By  developing  a  transactional  model  of  plan  construction,  we  can  allow  multiple  users  (for 
example,  the  ground,  maritime  and  air  components)  to  access  and  edit  the  same  plan.  Our  initial  relational 
database  approach  has  subsequently  been  subsumed  by  an  extensible  relational  model  called  the  Structured 
Data  Model  (SDM).  The  goal  of  the  SDM  has  been  to  provide  a  uniform,  easy  to  use,  and  complete 
representation  of  planning  data  so  that  tools  developed  by  various  AcT  researchers  can  more  easily 
interoperate. 

The  most  important  challenge  has  been  to  abduce  the  cause-effect  stmcture  of  a  special  operation  plan  from 
the  temporal  representation  entered  in  SOFTools  Temporal  Plan  Editor.  The  value  of  the  causal  graph  was 
recognized  early  on  as  a  representation  that  captures  the  dependencies  in  the  plan  that  were  not  otherwise 
explicitly  represented  in  the  temporal  plan  representation.  As  we  further  developed  our  causal  modeling 
approach  the  concept  of  the  relational  representation  became  secondary.  The  primary  focus  emerged  as  the 
automated  building  of  default  causal  models  from  the  plan  authoring  input  directly  using  the  XML 
representation.  The  causal  dependency  depicted  in  the  graph  is  only  potential  causality  expressing 
consistent  “happened  before”  relation.  The  heuristics  exploit  the  locality  inherent  in  the  temporal  editor 
where  plans  are  composed  of  subplans  of  movements  and  places.  The  potential  causality  information  can 
then  be  edited  by  the  user  by  adding  or  removing  edges  to  reflect  causal  semantics  not  captured  in  the 
temporal  plan  representation. 

Causal  views  can  provide  significant  enhancement  to  the  conventional  approach  of  monitoring  plan 
execution  using  checklists.  Execution  checklists  can  become  very  large,  and  events  that  indicate  related 
activities  at  a  high-level  view  of  the  plan  may  appear  to  be  widely  separated  by  other  events  and  by  time. 
And  there  may  be  a  lot  of  irrelevant  events  mixed  in  with  ones  of  interest.  This  means  that  when  we  view  a 
large  execution  checklist,  and  an  event  that  indicates  a  failed  or  delayed  execution  turns  up,  we  cannot 
immediately  focus  on  the  other  events  in  the  checklist  that  led  up  to  the  failure,  nor  can  we  quickly 
determine  impact  on  future  events.  Instead,  we  have  to  use  a  lot  of  knowledge  about  the  mission  and  the 
executing  plan  to  try  to  figure  it  out.  The  causal  views  can  be  used  to  monitor  event  logs  at  any  abstraction 
level  during  plan  execution,  to  detect  inconsistencies  with  prior  events,  to  determine  violations  of  critical 
requirements  and  impact  on  future  operations. 
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Causality  can  also  enhance  plan  authoring  in  a  different  way.  We  can  use  causality  to  retrieve  similar  plans 
from  historical  databases.  We  developed  an  algorithm  for  computing  complete  or  partial  matching  between 
plans  based  on  their  causal  models.  The  basic  idea  of  the  algorithm  is  that  two  plans  are  similar  if  their 
causal  structures  overlap.  That  is,  if  they  have  consistent  causal  ordering  and  the  nodes  in  the  ordered 
causal  families  have  the  same  type  and  same  number  of  parents.  We  did  some  preliminary  work  in  that 
direction  in  collaboration  with  other  team  members  in  the  context  of  case  based  reasoning  and  hierarchical 
task  networks. 
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12.  Conclusions 

We  developed  in  this  project  a  computational  approach  and  an  automated  tool  for  abducing  parsimonious 
representation  of  causal  dependencies  in  a  plan  authored  by  humans  in  mixed  initiative  environment.  The 
tool  is  designed  for  the  SOF  planning  domain  and  takes  as  input  a  plan  created  by  a  human  planner  using 
custom  graphical  interface  (a  program  called  SOFTools  TPE)  and  outputs  a  minimal  DAG  representing  a 
parsimonious  potential  causality  graph.  The  nodes  of  the  DAG  are  the  actions  and  the  directed  arcs 
represent  potential  causal  links  and/or  threat  resolution  links  as  commonly  defined  in  partial  order  planners. 
The  term  “potential”  emphasizes  the  uncertainty  in  the  abduced  links  since  no  requirement  is  placed  on  the 
availability  of  domain  theory.  Our  approach  relies  on  the  structural  information  only;  namely  the  temporal 
ordering  of  the  actions  and  the  task  hierarchy  of  the  plan.  The  DAG  is  presented  graphically  to  the  human 
modeler  for  validation  and  further  refinement.  The  plan  author  can  amend  the  potential  causality  structure 
by  graphically  adding  or  deleting  directed  arcs  in  the  DAG.  The  validated  causal  graph  captures  the 
knowledge  relevant  to  the  causal  dependencies  in  the  plan  and  can  then  be  used  for  reasoning  tasks  such  as 
ran-time  replanning.  There  are  a  number  of  areas  for  future  extensions  of  the  technology.  One  area  is  to 
exploit  the  causal  model  to  speed  up  the  plan  authoring  by  fetching  similar  plans  from  a  case-based  library 
of  plans.  We  have  developed  an  algorithm  to  compute  plan  similarity  that  can  be  embedded  in  a  case -based 
reasoning  system.  Another  area  is  to  integrate  with  qualitative  reasoning  approaches  in  planning  for 
reasoning  with  incomplete  information.  Requiring  complete  domain  models  or  expecting  the  human 
planner  to  specify  every  condition  required  by  the  plan  operators  is  not  realistic  in  large  military  and  space 
applications.  Our  potential  causality  approach  can  be  supplemented  with  qualitative  knowledge  to  address 
the  problem  of  lack  of  complete  domain  models. 
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